Large information systems utilizing a single database which is shared by a number of simultaneous independent users are becoming commonplace. In such systems, the users typically have the ability to add, delete and modify separate data entries, or records, in the centralized database and, therefore, it is imperative to control access by each individual user to each record so that two users do not modify the same record at the same time. If simultaneous access to records is not carefully controlled, a so-called "concurrent use" problem arises.
Specifically, in a typical database, database operations such as adding, modifying or deleting records are performed by the users at physically separate terminals which may be located remotely from each other. Each user enters information into the terminal to enable the database system to perform a requested operation, but generally the actual changes to the record are not made until the user has completed a requested change at the terminal and then initiated an update procedure by an additional operation (for example by selecting a "store" button on a graphic user interface). In some database systems, users may actually simultaneously request different changes to the same record at two different terminals.
However, the database software which actually makes the changes to the records performs the update operation in a serial fashion. If change requests to the same record are made simultaneously, special arbitration routines decide which request will be handled first. In such a system, if simultaneous access to records is allowed, a record may be modified by one user and then immediately changed by another user, resulting in erroneous or confusing results.
Consequently, most modern database systems utilize some type of record "locking" procedure which prevents simultaneous access to the same record. Typically, such systems require that a particular record be "read" before modification of the record is attempted. When a record is "read", the database system marks the record as "in use". Subsequently, if another user requests access to the "in use" record by attempting to read the record, a notification is sent to the second user indicating the record is not available because it is being modified by a prior user. This record locking scheme, sometimes referred to as the "pessimistic locking model", generally works well and prevents the confusion and errors which result from simultaneous access.
However, in some circumstances, the aforementioned record locking scheme can create problems, for example, in systems where each record contains a large amount of information. Inefficiency results due to the fact that an entire record must be locked even if only a small portion is being modified; therefore, a user who wishes to update a locked record must wait until the record is free, even if another user is modifying a completely different part of the record.
For example, the latter situation can occur in a hospital setting in which care providers enter information concerning patients into a medical information system. The information may include patient status information such as pulse rate, respiration and other such variables (measured over time) and may also include information such as medication administered and tests performed. Such a medical information system operates analogously to a well-known manual flowsheet system in which patient information, readings, notes and comments are added serially, row-by-row to a paper record, known as a flowsheet, which is kept at the patient's bed.
Typically, in a medical information system, information is entered into a database for each patient by a variety of users, including doctors, respiratory therapists, clinical laboratories, nurses, and bedside devices, which automatically generate patient information. Many of these users are mobile and may not be in the vicinity of a given patient when they desire to enter information for that patient. Consequently, care providers are generally allowed to update the medical database from a variety of computer terminals placed at separate physical locations.
Since the amount of information added to the flowsheet can be substantial and continuously grows, the system quickly becomes inefficient if the entire flowsheet is locked each time a care provider enters or modifies information. The inefficiency is especially unfortunate because, although possible, it is unlikely that two different care providers will actually be modifying the same area of the flowsheet due to the fact that many care providers are specialized. It is possible to lock only portions of the flowsheet, so that two care providers operating on different areas of the flowsheet can concurrently enter or modify information, but due to the interrelationship of many flowsheet areas, such partial locking schemes are complicated and cumbersome.
Therefore, to avoid inefficiency, it is desirable to allow two or more separate care providers to enter or modify (collectively referred to as "chart") data concurrently for a single patient, so that no user has to wait while other users chart information. With such a concurrent entry system, it is critical that the data entered be consistent and that all users be informed when changes to the data are made, so that potentially serious errors do not occur.
Another approach to accessing database records is referred to as the "optimistic locking model". The user proceeds with a transaction, such as the updating of a record, on the assumption that there is no conflict. When the user attempts to commit the transaction, such as by storing the new information, the database software determines if there was a conflict with another user. If a conflict is found, the transaction is aborted. This approach enables all users to proceed without waiting. However, the transaction may be aborted at the end. The optimistic approach is undesirable in a medical information system, since the user may be required to reenter the information for updating the record, thus wasting valuable time.
One recordkeeping feature that has been used in connection with updating records in medical information systems is a correction history. The correction history contains a record of each change to each parameter in the patient flowsheet. Each entry in the correction history indicates the value of a parameter that was corrected, the user that made the correction and the time of the correction. Thus, the hospital has a complete record of all changes to each patient flowsheet. The correction history is particularly important in a hospital environment, which often involves life and death situations and may require later analysis of events that occurred during the care of a particular patient.